TL;DR The main change in this PR is in the Q2 class, enabling failure when the PrometheusMeterRegistry won't register a Meter instead of Micrometer silently accepting it. (there are a couple of extra minor things in other classes)

Problem

Micrometer, allows the registration of multiple meters under the same name but with a different set of Tag keys.
(here I'm considering just the set of tag keys, not their values).
That means, I can register two meters, such as Counters with name jpos.bbb.stats and

• one with tags {xxx="123", yyy="456"}
• one with tags {xxx="123", yyy="456", zzz="789"}

Micrometer will happily accept that, and register both under its own registry, and it will return both valid and functioning Meter instances, that you can increment, and query their current count, etc. from the Java code.
You can query the Micrometer registry and find both counters happily living there.

However, the underlying Prometheus registry will silently reject the second one because meters with the same name must have the exact same set of tag keys.
I say "silently", when in fact you will just get a stderr warning, that is very easy to miss, such as

WARNING: The meter (MeterId{name='jpos.bbb.stats', tags=[....]}) registration has failed: Prometheus requires that all meters with the same name have the same set of tag keys. There is already an existing meter named 'jpos_isomsg' containing tag keys [....]. The meter you are attempting to register has keys [....]. Note that subsequent logs will be logged at debug level.

So, your second meter wont be available for scraping.

The problem is that there is no easy way, programmatically, know that your meter failed to register under Prometheus.
By default, there is no boolean false, no null, not even an exception. There is no way to ask the returned Meter "have you been successfully registered?" Furthermore, when querying the PrometheusMeterRegistry itself, the failed Meter appears in the list.

All other solutions found, after long research, involve very expensive querying and streaming of obscure lists of internal objects.

Solution

The quick fix is to enable throwExceptionOnRegistrationFailure() on the PrometheusMeterRegistry.
So now, when you attempt registering an conflicting Meter, three good things happen:

1. you get an IllegalStateException (This is an unchecked exception, so it could be catched or not.)
2. Your MeterXYZ.builder(...etc...).register(reg) returns null, and you can check the return value if you don't want to catch the exception, and act accordingly.
3. The Meter will not be registered. It will not appear when you do Search.in(reg) or other similar queries.